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DETAILED ACTION 

This Office action is in response to Applicant's amendments and comments filed 
on November 5, 2004. Claims 1-50 are presented for further examination. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

1 . Claims 1 -4, 9-20, 25-37, 39, 41 -43, 45, and 47-50 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Humpleman et al. (U.S. Patent No. 
6,546,419, hereinafter "Humpleman"), in view of Duffy ("HP Intros Mgmt. Apps for 
Router Nets, from Network World, 1 994), and further as supported by Weschler, Jr. , 
(U.S. Patent No. 6,757,720, hereinafter "Weschler). 

In considering claim 1, Humpleman discloses a method for controlling a service 
in a network device ("device B"), comprising the steps of: 

receiving at the network device a document written in accordance with a markup 
language ("interface document INTERFACE. XML") and a corresponding document 
definition ("document type definition INTERFACE. DTD") (col. 15, lines 44-52; col. 18, 
lines 8-11, "the XMLRPC command messages are sent to the controlled device B over 
the network. Upon receiving said XMLRPC command messages..."), wherein the 
document describes a service (col. 18, lines 12-16, "requested services"); 
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Means for parsing by the network device the received document in accordance 
with the corresponding document definition (col. 18, lines 11-13, "the controlled 
application 84 of device B uses the XML parser 74 of device B to parse and interpret the 
received XML command messages"); 

Means for executing the service on the network device in accordance with the 
parsed document (col. 18, lines 14-17, "device B then decodes the parser results... to 
perform requested services"). 

However, Humpleman does not disclose that the service, device, and document 
relate to data forwarding, such that the document causes data forwarding services to be 
performed. Instead, Humpleman teaches using the above technique for controlling 
client/server services on a home network. 

Nonetheless, it is well known to remotely control and manage not only home 
devices on a home network, but also routing devices on a routing network, as 
evidenced by Duffy. Duffy discloses that as far back as 1994, network applications 
were able to control and manage forwarding services on routers over a network ("from 
this PC, users can assign addresses, check for duplicate addresses and errors, use 
point-and-click commands to 'connect' routers... and validate configuration parameters 
for all routers," 3; "configuration files stored in a central file server and manually 
uploaded to the server and management station, and downloaded to AdvanceStack 
routers," U 4). Furthermore, it is well known to control and manage such devices using 
XML, as evidenced by Weschler (col. 9, line 67 - col. 10, line 3, "Routers, switches, 
network ports, and other network devices recognize XML formatted documents 



Application/Control Number: 09/692,949 Page 4 

Art Unit: 2153 

embedded in HTTP data transport packets and are configured to handle them 
appropriately and reliably"). 

Given the teaching of Duffy and Weschler of using XML to control network 
routers, a person having ordinary skill in the art would have readily recognized the 
desirability and advantages of using the particular XML remote management document, 
definition, and parsing method taught by Humpleman to control network routers using 
XML, because XML is "well understood, actively developed, and readily transportable 
through a variety of communications media," (Weschler, col. 9, lines 63-65) and would 
thus allow comprehensive management of network routers with few development costs. 

In considering claim 17, Humpleman discloses a network device ("device B") for 
locally performing a data forwarding service in response to a remote request, 
comprising: 

Means for receiving at the network device a document written in accordance with 
a markup language ("interface document INTERFACE. XML") and a corresponding 
document definition ("document type definition INTERFACE. DTD") (col. 15, lines 44-52; 
col. 18, lines 8-11, "the XMLRPC command messages are sent to the controlled device 
B over the network. Upon receiving said XMLRPC command messages..."); 

Means for parsing by the network device the received document in accordance 
with the corresponding document definition (col. 18, lines 11-13, "the controlled 
application 84 of device B uses the XML parser 74 of device B to parse and interpret the 
received XML command messages");. 
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Means for executing the service on the network device in accordance with the 
parsed document (col. 18, lines 14-17, "device B then decodes the parser results... to 
perform requested services"). 

However, Humpleman does not disclose that the service, device, and document 
relate to data forwarding, such that the document causes data forwarding services to be 
performed. Instead, Humpleman teaches using the above technique for controlling 
client/server services on a home network. 

Nonetheless, it is well known to remotely control and manage not only home 
devices on a home network, but also routing devices on a routing network, as 
evidenced by Duffy. Duffy discloses that as far back as 1994, network applications 
were able to control and manage forwarding services on routers over a network ("from 
this PC, users can assign addresses, check for duplicate addresses and errors, use 
point-and-click commands to 'connect' routers... and validate configuration parameters 
for all routers," 3; "configuration files stored in a central file server and manually 
uploaded to the server and management station, and downloaded to AdvanceStack 
routers," 4). Furthermore, it is well known to control and manage such devices using 
XML, as evidenced by Weschler (col. 9, line 67 - col. 10, line 3, "Routers, switches, 
network ports, and other network devices recognize XML formatted documents 
embedded in HTTP data transport packets and are configured to handle them 
appropriately and reliably"). 

Given the teaching of Duffy and Weschler of using XML to control network 
routers, a person having ordinary skill in the art would have readily recognized the 
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desirability and advantages of using the particular XML remote management document, 
definition, and parsing method taught by Humpleman to control network routers using 
XML, because XML is "well understood, actively developed, and readily transportable 
through a variety of communications media," (Weschler, col. 9, lines 63-65) and would 
thus allow comprehensive management of network routers with few development costs. 

In considering claims 2 and 18, Humpleman further discloses the means for 
executing including means for interfacing with hardware and software on the network 
device (col. 15, lines 11-15, "in each device 14, applications at the top of the 
communication stack send and receive communication messages over the network, and 
communicate with software layers in the device stack that locally control the device 
hardware or service software for the device"). 

In considering claims 3 and 19, Humpleman further discloses that the markup 
language is XML ("XML"). 

In considering claims 4 and 20, Humpleman further discloses that the 
corresponding document definition is an XML DTD ("DTD"). 

In considering claims 9 and 25, Humpleman further discloses that the means for 
parsing include means for parsing from the document an identifier ("method name") 
corresponding to the service (col. 18, lines 13-17). 
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In considering claims 10 and 26, Humpleman further discloses that the means for 
parsing include means for parsing from the document runtime parameters- 
corresponding to the service (col. 12, lines 63-65, "the look-up 56 table provides run- 
time translation of XML object method calls from Service B into device native language 
calls for Service A"). 

In considering claims 1 1 and 27, Humpleman further discloses means for 
instantiating an object corresponding to the service in accordance with the parsed 
identifier (col. 18, lines 19-21 , "launch the native function implementations of device B"). 

In considering claims 12 and 28, Humpleman further discloses means for 
instantiating an object corresponding to the service in accordance with the parsed 
identifier and the parsed runtime parameters (col. 18, lines 19-21, "launch the native 
function implementations of device B," col. 12, lines 60-65, "run-time translation of XML 
object method calls"). 

In considering claims 13 and 29, both Weschler and Duffy further disclose that 
the network can be one of a multitude of devices, including a router. 

In considering claims 14 and 30, both Weschler and Duffy further disclose that 
the network device comprises a packet forwarding architecture (i.e. a router). 
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In considering claims 15 and 31, Humpleman further discloses means for 
preparing a response corresponding to the executed service (col. 18, lines 21-24, 
"responses"). 

In considering claim 16 and 32, Humpleman further discloses means for 
forwarding the response to a remote requestor of the service (col. 18, lines 23-24, 
"responses [are] sent to the controller device A"). 

In considering claim 33, Humpleman discloses a network device ("device B") for 
locally performing a service in accordance with a received document written in a 
document markup language ("interface document INTERFACE.XML"), comprising: 

Means for receiving at the network device a document written in accordance with 
a markup language ("interface document INTERFACE.XML") and a corresponding 
document definition ("document type definition INTERFACE. DTD") (col. 15, lines 44-52; 
col. 18, lines 8-11, "the XMLRPC command messages are sent to the controlled device 
B over the network. Upon receiving said XMLRPC command messages..."); 

A parser that is adapted to parse the received document in accordance with the 
corresponding document definition to obtain an identifier of the service (col. 18, lines 11- 
16, "the controlled application 84 of device B uses the XML parser 74 of device B to 
parse and interpret the received XML command messages," wherein the identifier is the 
"method name"); and 
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A service launcher that is adapted to launch the service corresponding to the 
identifier parsed from the received document (col. 18, lines 17-21 , "device B then uses 
the XML... to access and launch the native function implementation of device B..."). 

However, Humpleman does not disclose that the service, device, and document 
relate to data forwarding, such that the document causes data forwarding services to be 
performed. Instead, Humpleman teaches using the above technique for controlling 
client/server services on a home network. 

Nonetheless, for the same reasons already discussed with regard to claims 1 
and 17, it would have been obvious to use the Humpleman XML remote management 
document, definition, and parsing method taught by Humpleman to control data 
forwarding services on a network. 

In considering claim 34, Humpleman further discloses a network data transfer 
service that is adapted to communicate with remote devices for receiving the document 
(col. 16, lines 13-16, "a Home Network Device Web server 86 in each of the devices A 
and B manages communication between the devices over the network"). 

In considering claim 35, Humpleman further discloses that the network data 
transfer service comprises an HTTP server ("Web server 86"). 

In considering claim 36, Humpleman further discloses that the markup language 
is XML ("XML"). 
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In considering claim 37, Humpleman further discloses that the corresponding 
document definition is an XML DTD ("DTD"). 

In considering claim 39, Humpleman further discloses a services storage coupled 
to the service launcher that stores a plurality of services, the service launcher being 
further adapted to select the service from the stored plurality of services in accordance 
with the parsed identifier (col. 18, lines 9-21, wherein the parsing obtains method call 
information and a method name, which are used to select from the plurality of services - 
i.e. handlers » to perform the service). 

In considering claim 41 , Weschler and Duffy both disclose that the device further 
comprises a packet forwarding switch fabric (i.e. "routers," and "switches"). 

In considering claim 42, Weschler further discloses that the launched service 
causes changes in how packets are forwarded through the switch fabric (i.e. assigning 
addresses and connecting routers causes changes in how packets are forwarded 
through the switch fabric). 

In considering claim 43, Weschler further discloses that the management system 
can also monitor performance of packet forwarding in the routers (p. 2, U 2, "Traffic 
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Monitor lets network managers analyze traffic patterns on all LAN segments and wide- 
area links from a single Windows PC or Unix workstation"). 

in considering claim 45, Humpleman further discloses device APIs for 
interoperating with the device hardware and software for executing launched services 
(col. 14, lines 20-25, "API interface"). 

In considering claim 47, Humpleman further discloses device APIs for 
interoperating with the device hardware and software for executing launched services 
(col. 14, lines 20-25, "API interface"). 

In considering claim 48, Humpleman discloses a method for causing a network 
device to locally perform a service, comprising the steps of: 

Identifying the service to be performed at a remote client computer, and 
preparing at the remote client computer a document written in a markup language in 
accordance with a document definition, the document including an identifier of the 
service (col. 18, lines 3-10, wherein "device A" generates the XML document to send a 
command message to device B, the document inherently including an identifier of the 
service - see Example 1, line 45, wherein "DVCR1. record" identifies the service); 

Transmitting the document to the network device (col. 18, lines 8-9); 
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Identifying at the network device the document definition corresponding to the 
transmitted document (col. 18, lines 10-16; col. 15, lines 44-52, wherein the DTD file 
corresponding to the document is also received and identified at the network device); 

Parsing by the network device the transmitted document in accordance with the 
corresponding document definition (col. 18, lines 10-16, "parse and interpret the 
received XML command messages"); and 

Executing the service on the network device in accordance with the parsed 
document (col. 18, lines 12-17, "perform requested services"). 

However, Humpleman does not disclose that the service, device, and document 
are related to a data forwarding service. Nonetheless, for the same reasons already 
discussed with regard to claims 1 and 17, it would have been obvious to use the 
Humpleman XML remote management document, definition, and parsing method taught 
by Humpleman to control data forwarding services on a network. 

In considering claim 49, Humpleman further discloses that the markup language 
is XML ("XML"). 

In considering claim 50, Humpleman further discloses that the corresponding 
document definition is an XML DTD ("DTD"). 
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2. Claims 5-8, 21-24, and 38 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Humpleman, in view of Weschler and Duffy, and further in view of 
Gessner (U.S. Patent Publication No. 2002/0032709, filed on Sep. 29, 1998). 

In considering claims 5, 7, 21, and 23, these claims all recite retrieving the 
corresponding document definition from a plurality of document definitions in 
accordance with an identifier in the received document. Humpleman teaches a 
document definition corresponding to a document, but remains silent regarding how the 
document definition is selected or retrieved. Nonetheless, selection at run time of 
document definitions that correspond to a selected markup language document is well 
known, as evidenced by Gessner. Gessner discloses a system that uses DTDs and 
their corresponding documents, wherein the DTDs "may be locally stored [or] may be 
stored remotely on server systems and delivered at and during run time of a browser, 
etc. to facilitate dynamic replacement of particular grammars and to further facilitate the 
rendering of content based thereon." See U [0041 ]. Thus, a person having ordinary skill 
in the art would have readily recognized the desirability and advantages of selecting the 
corresponding DTDs in the system taught by Humpleman, Weschler, and Duffy 
according to the id contained in the documents, to facilitate dynamic creation of the XML 
file, thereby further enhancing the dynamic nature of the control and command system 
taught by Humpleman, Weschler, and Duffy (see Humpleman, col. 2, lines 39-41). 
Therefore, it would have been obvious to use the dynamic DTD selection taught by 
Gessner in the dynamic control and command system taught by Humpleman, Weschler, 
and Duffy. 
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In considering claims 6, 8, 22, and 24, Gessner further discloses that the 
document definitions are provided locally ([0041], "DTD components may be locally 
stored"). 

In considering claim 38, claim 38 contains the same limitations as claims 5, 7, 21, 
and 23, but adds the feature that the device further comprises a document definition 
storage that stores the plurality of definitions from which selection is made. This 
storage feature is further taught by Gessner in U [0041], which recites "DTD components 
may be locally stored." 

3. Claims 40 and 46 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Humpleman, Weschler, and Duffy, in view of Applicant's admission of the prior art, 
or alternatively in view of Jaeger et al. (Dynamic Classification in Silicon-based 
Forwarding Engine Environments, December 1999, hereinafter "Jaeger"). 

In considering claim 40, Humpleman teaches that the service launcher is 
adapted to launch the service using a runtime environment (col. 18, lines 10-21 
describe that the service launcher generates native function implementations from the 
XML document, and col. 12, lines 55-65 describe that such translation occurs at run- 
time). However, Humpleman does not disclose the use of the "Oplet Runtime 
Environment." Nonetheless, the Oplet Runtime Environment is a well-known 
environment in the router environment, as evidenced by both Applicant's admission of 
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prior art (see specification, p. 9, lines 8-16), and by Jaeger (Abstract). A person having 
ordinary skill in the art would have readily recognized the desirability and advantages of 
using the ORE to manage the routers in the system taught by Humpleman, Weschler, 
and Duffy because ORE "supports the creation of services in Java that are extensible, 
portable, and easily distributed over the network," (see Jaeger, Conclusion, p. 109). 
Thus, it would have been obvious to use the Oplet Runtime Environment as the runtime 
environment in the system taught by Humpleman, Weschler, and Duffy. 

In considering claim 46, Humpleman further discloses device APIs for 
interoperating with the device hardware and software for executing launched services 
(col. 14, lines 20-25, "API interface"). 

4. Claim 44 is rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
Humpleman, Weschler, and Duffy, in view of Dobbins et al. (U.S. Patent No. 5,951,649, 
hereinafter "Dobbins"). 

In considering claim 44, although the system taught by Humpleman, Weschler, 
and Duffy discloses substantial features of the claimed invention, it fails to disclose that 
launched service accesses a MIB on the network device. Nonetheless, Duffy discloses 
changing router configuration by altering 'connections' between routers. Furthermore, 
as shown by Dobbins, it is well known that one way to represent connections between 
routers and other forwarding functions is through a MIB (col. 6, lines 41-55). Thus, 
given this knowledge, it would have been obvious to alter the router connections in the 
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system taught by Humpleman, Weschler, and Duffy by altering a MIB, because a MIB 
structure can be easily changed and understood by an administrator (see Dobbins, col. 
6, lines 52-55). 

Response to Arguments 

5. Applicant's request for reconsideration filed on November 5, 2004 has been fully 
considered, but is unpersuasive. In considering Applicant's remarks, the following 
arguments are noted: 

a. The service capabilities described using XML or the like in Humpleman et al. are 
different in kind from data forwarding services controlled by parsing of XML documents 
by the present invention. 

b. The combined references include no hint or suggestion of controlling data 
forwarding service in a data forwarding device by parsing a received document in 
accordance with a correspond document definition, wherein the parsing determines at 
least one parameter describing a data forwarding service. 

In considering (a), Applicant contends that the service capabilities described 
using XML or the like in Humpleman et al. are different in kind from data forwarding 
services controlled by parsing of XML documents by the present invention. Examiner 
agrees that the home networking services specifically described in Humpleman are 
different in kind from the claimed "data forwarding services." Nonetheless, Humpleman 
generally describes that the home network devices can include "computers, peripheral 
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devices, routers , storage devices, and appliances" (col. 1, lines 36-37), and that "an 
example of a network is a home network" (col. 1 , lines 38-39), and that "the term 
'device' typically includes logical devices or other units having functionality and an ability 
to exchange data, and can include not only all home devices but also general purpose 
computers" (col. 1, lines 42-44). Thus, although Humpleman does not specifically 
describe particular data forwarding services in its specification, it certainly contemplates 
that they constitute part of the system. Consequently, Humpleman's disclosure would 
not preclude a person of ordinary skill in the art from recognizing that the same XML 
document-control method used for the devices in Humpleman could be used to control 
other network-connected devices, such as routers. Humpleman's disclosure instead 
encourages it. 

In considering (b), Applicant contends that the combined references include no 
hint or suggestion of controlling data forwarding service in a data forwarding device by 
parsing a received document in accordance with a correspond document definition, 
wherein the parsing determines at least one parameter describing a data forwarding 
service. Examiner respectfully disagrees. 

As discussed in (a) above, Humpleman taken alone at least suggests using the 
parsing technique claimed to control all kinds of network devices and services, one of 
which may include a router. Furthermore, Duffy discloses that as far back as 1994, 
network applications were able to control and manage forwarding services on routers 
over a network ("from this PC, users can assign addresses, check for duplicate 
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addresses and errors, use point-and-click commands to 'connect' routers... and validate 
configuration parameters for all routers," H 3; "configuration files stored in a central file 
server and manually uploaded to the server and management station, and downloaded 
to AdvanceStack routers," 1J 4). Furthermore, it is well known to control and manage 
such devices using XML, as evidenced by Weschler (col. 9, line 67 - col. 10, line 3, 
"Routers, switches, network ports, and other network devices recognize XML formatted 
documents embedded in HTTP data transport packets and are configured to handle 
them appropriately and reliably"). Thus, for these reasons, as further elaborated in the 
claim rejections above, the combination of Humpleman, Duffy, and Weschler discloses 
all of the features of the claimed invention and suggests combining them in the manner 
claimed. 

Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
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the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Bradley Edelman whose telephone number is 571-272- 
3953. The examiner can normally be reached from 9 a.m. to 5 p.m. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached at 571-272-3949. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-21 7-91 97 (toll-free). 




BE 

April 25, 2005 



